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REMARKS 

In the Office Action, the Examiner rejected the claims under 35 USC §103. These 
objections and rejections are fully traversed below. Applicant has amended the claims to 
correct various typographical errors and to further clarify the subject matter regarded as the 
invention Claims 1-2, 4-7, 9-23, 25-28, 30-50, 52-53, 55-56, 58-61, and 63-66 remain 
pending- 
Reconsideration of the application is respectfully requested based on the following 
remarks. 

REJECTION OF CLAIMS UNDER 35 USC §103 

In the Office Action, the Examiner rejected claims 1-2, 4-5, 7-14, 22-23, 25-26, 28- 
35, 44-49, 53-56, 58-60, and 63-66 under 35 USC § 103(a) as being unpatentable over 
Wakayaxna et al, U.S. Publication No. US 2001/0049739 Al, ('Wakayattia 1 hereinafter) in 
view of IshizaM, US Publication No. US 2003/0101239 Al, CIshizaki' hereinafter). 

While the Examiner indicates that these claims are rejected further in view of Rosen, 
U-S. Patent No. 6,337,861 Bl, ('Rosen' hereinafter), Applicant was unable to find a reference 
or specific citation to Rosen in any of these claim rejections. 

Each of the pending claims recites the encapsulation of a packet or frame with a 
virtual storage area network identifier and a type of traffic. Through the identification of a 
traffic type, frames carrying a variety of traffic types may be transmitted within a VS AN. 
Moreover, multiple VSANs, each capable of supporting different traffic types, may be 
interconnected through the identification of a traffic type in the newly appended header. The 
cited references fail to disclose such a need in the prior art, or a solution such as that claimed. 

With respect to independent claim 1, as amended, recites "encapsulating the packet or 
frame with a virtual storage area network identifier, a type of traffic to be carried by the 
packet or frame, and information specifying at least one of a TTL value or MPLS 
information, wherein encapsulating comprises appending a header to the packet or frame to 
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create a new packet or frame, wherein the header includes fields for the virtual storage area 
network identifier and information specifying at least one of the TTL value or the MPLS 
information, wherein the header further includes a field specifying the type of traffic to be 
carried by the packet or frame, wherein the field specifying the type of traffic to be carried by 
the packet or frame includes a first type when the type of traffic is a first one of two or more 
available types of traffic and the field includes a second type when the type of traffic is a 
second one of the two or more available types of traffic, wherein the two or more available 
types of traffic include at least one of Ethernet, fibre channel, and lhfiiiiband." 

Independent cl aim 55 recites in relevant part, "encapsulating the packet or frame with 
a virtual storage area network identifier and information specifying a type of traffic to be 
carried by the packet or ftame y wherein the field specifying the type of traffic to be carried by 
the packet or frame includes a first type when the type of traffic is a first one of two or more 
available types of traffic and the field includes a second type when the type of traffic is a 
second one of the two or more available types of traffic, wherein the two or more available 
types of traffic include at least one of Ethernet, fibre channel, and Infiniband, wherein 
encapsulating comprises adding a header to the packet or frame to create a new packet or 
frame, wherein the header includes fields for the virtual storage area network identifier and 
the information specifying the type of traffic to be carried by the packet or frame." 

With respect to independent claims 1 and 55, neither of the cited references, 
separately or in combination, discloses or suggests "encapsulating the packet or frame with a 
virtual storage area network identifier and information specifying a type of traffic to be 
carried by the packet or frame, wherein encapsulating comprises adding a header to the 
packet or frame to create a new packet or frame, wherein the header includes fields for the 
virtual storage area network identifier and the information specifying the type of traffic to be 
carried by the packet or frame." In fact, neither of the cited references discloses or suggests 
encapsulating the packet or frame with a VSAN identifier. Moreover, each of the cited 
references fails to disclose or suggest encapsulating a packet or frame with a header including 
a field specifying the type of traffic to be carried by the packet or frame, where "the field 
includes a first type when the type of traffic is a first one of two or more available types of 
traffic and the field includes a second type when the type of traffic is a second one of the two 
or more available types of traffic, wherein the two or more available types of traffic include at 
least one of Ethernet, fibre channel, and Infiniband*" as claimed. The Examiner cites FIG. 9 
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of Wakayama, which discusses the configuration of the lower layer processor for the 
Ethernet, and discusses the processing of an Ethernet frame. However, there is no indication 
that the header includes information Specifying the type of traffic to be carried by the frame. 
In fact, FIG. 9 of Wakayama clearly indicates that only one type of traffic - Ethernet - is 
being transmitted in the VLAN described- As a result, it would be unnecessary to 
encapsulate a packet such as an Ethernet packet with an additional header to specify the type 
of traffic within that header. The cited references, separately or in combination, fail to 
disclose or suggest identifying the type of traffic within a VSAN. In fact, as set forth above, 
each of the cited references relates to a VLAN, in which a single type of traffic is typically 
used, and therefore teaches awav from enabling multiple types of traffic to be transmitted. 
Accordingly, Applicant respectfully submits that the claims are patentable over the cited 
references. 

As set forth in the Background section of Applicant's specification, encapsulation 
mechanisms for transporting packets between ports of switches in a network on the basis of 
VLAN associations among those ports are in existence. One such encapsulation mechanism 
is ISL, developed by Cisco Systems. However, ISL does not support multiple different 
protocols on a single physical network infrastructure. Thus, current technology fails to 
address the need for supporting a multiple SAN system in which different protocols or 
technologies simultaneously co-exist. It is important to note that operating multiple different 
protocols is desirable in a SAN in order to support different storage devices operating under 
different protocols. This problem would not be immediately obvious in a VLAN 
environment in which a single protocol is typically used. Moreover, ISL was not optimized 
for Fibre Channel transmissions, and therefore could not easily be implemented in modern 
SANs. 

In addition, it is important to note that both of the references cited by the Examiner, 
Wakayama and Ishizaki, relate to a VLAN, not a VSAN. More particularly, Wakayama 
discloses providing a VLAN ID in a header of a packet. See Abstract. Thus, the cited art 
relates to a VLAN identifier rather than a VSAN identifier. 

The Examiner asserts in the recent Office Action that a SAN is well known in the art, 
citing Tamura et al (U.S. Patent No. 6,728,848). The Examiner further cites Ishizaki (US 
2003/0101239 Al). However, it is unclear in what capacity the Ishizaki reference is cited. In 
the previous Office Action, die Examiner stated that Ishizaki also teaches storage devices 
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using a Virtual Local Area Network. Even, though SANs are, in fact, well-known in the art, 
the references fail to disclose or suggest the claimed invention for use in a VSAN. 

It i$ also important to note that a SAN denotes a physical infrastructure. In contrast, 
the invention of claim 1 relates to VSANs. As set forth in the Summary of the Invention on 
page 4 of Applicant's specification, "[t]hrough the concept of a VSAN, one or more network 
devices (e.g., servers) and one or more data storage devices are grouped into a logical 
network defined within a common physical infrastructure." 

The E xamine r cites the definition of a Storage Area Network defined by Tamura et al, 
which states that a ""Storage Area Network" or SAN for the purposes of the embodiments 
and claims of the present invention means any network, real or virtual, that has one of its 
primary functions to provide storage from one or more storage systems to one or more 
computer systems." While this definition has been set forth in Tamura, there is no evidence 
that this definition is universally accepted. 

While Tamura has not been officially cited in this rejection, it is important to note that 
the system of Tamura includes a single SAN. In other words, a SAN identifier is not 
provided in a packet or frame header. Stated another way, Tamura fails to disclose or suggest 
the use of a multiple SANs, or multiple VSANs, in a single network. Accordingly, Tamura 
teaches away from the claimed invention. 

The claimed invention enables different protocols to co-exist in a VSAN system. For 
instance, the type of MPLS information that may be specified in the header is recited in 
claims 17-20> From these claims, it can be seen that the presence and number of MPLS 
labels provided in the MPLS information can be indicated in the MPLS information/packet 
header. Thus, the MPLS information may vary, as necessary, with the protocol/type of 
traffic. In contrast, Wakayama indicates that a single MPLS label is associated with a VLAN 
ID. See Abstract. As such, Wakayama teaches away from indicating the presence and/or 
number of MPLS labels in the MPLS packet header. As another example, claims 8-10 enable 
the type of traffic to be specified. This information was previously not necessary, since 
multiple protocols could not be supported on a single physical network infrastructure. 
Neither of the cited references discloses supporting multiple protocols or types of traffic in 
this manner. 

Neither of the references discloses or suggests supporting multiple different protocols 
on a single physical network infrastructure. While operating multiple different protocols is 
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desirable in a SAN in order to support different storage devices operating under different 
protocols, this is not pertinent to the VLAN environment Thus, there was no need to specify 
various information in the packet, such as type of traffic or indicate whether MPLS labels are 
present (and if so, how many). As such, neither of the references discloses the problem 
present in the current technology pertinent to the SAN environment, nor do they suggest a 
solution to this problem. Moreover, since a single protocol/type of traffic is typically used in 
a VLAN environment, both Wakayama and Ishizaki teach away from supporting multiple 
different protocols in a network such as a SAN or VSAN. Accordingly, Applicant 
respectfully submits that the pending claims 1-2, 4-5, 7-14, 22-23, 25-26, 28-35, 44-49, 53- 
56, 58-60, and 63-66 are patentable over the cited references. 



In the Office Action, the Examiner rejected claims 6, 16-20, 27, 38-42, and 52 under 
35 USC §103(a) as being unpatentable over Wakayama in view of Ishizaki, further in view of 
Rosen, and further in view of Behzadi, U.S. Patent No. 6,728,220 B2, ('Behzadi' 
hereinafter). 

Although the Examiner has cited Rosen in these claim rejections, it is important to 
note that Applicant was unable to find a reference or specific citation to Rosen in any of the 
claim rejections. 

Behzadi discloses the use of a TTL field in combination with an MPLS label within a 
Shim header, as shown in FIG. 5. However, it is important to note that Behzadi relates to 
preventing transmission loops in a label switching domain. See Title. More particularly, the 
invention disclosed in Behzadi relates solely to preventing transmission loops in a ring 
network that utilizes label switching. See Abstract Behzadi fails to disclose or suggest 
preventing transmission loops in a network that is not a ring network. As such, Behzadi 
teaches away from preventing transmission loops in a network that is not a ring network 
using a TTL field. 

It is important to note that the claimed invention relates to a SAN rather than a ring 
network- Neither of the cited references discloses or suggests the routing problems that can 
occur within a SAN. More particularly, in some SANs, there maybe topology as well as 
routing problems that could cause a frame to traverse a loop within the network. As such, the 
references, separately or in combination, fail to disclose the use of the TTL field in a SAN 
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environment in the manner claimed. Moreover, Bebzadi fails to ewe the deficiencies of the 
primary references. Accordingly, Applicant respectfully submits that claims 6, 16-20, 27, 38- 
42, and 52 are patentable over the cited art. 

The Examiner rejected claims 15 and 36 under 35 USC § 1 03 under Wakayama in 
view of Ishizaki, further in view of Rosen and further in view of Walrand et al, U.S. Patent 
No. 6,674,760 Bl, ('Walrand' hereinafter) and rejected claims 21 and 43 under 35 USC §103 
under Wakayama in view of Ishizaki , further in view of Rosen and further in view of 
Aggarwal et al, US 2002/0101868 Al, (' Aggarwal 1 hereinafter). These rejections are fully 
traversed below. 

The additional references Walrand and Aggarwal fail to cure the deficiencies of the 
primary references. It is also important to note that the Examiner has failed to reference 
Rosen or cite a specific portion of Rosen in any of tike claim rejections. Accordingly, 
Applicant respectfully submits that claims 15, 36, 21 and 43 are patentable over the cited 
references. 

Based on the foregoing, it is submitted that the independent claims are patentable over 
the cited references. In addition, it is submitted that the dependent claims are also patentable 
for at least the same reasons. The additional limitations recited in the independent claims or 
the dependent claims are not further-discussed as the above-discussed limitations are clearly 
sufficient to distinguish the claimed invention from the cited references. Thus, it is 
respectfully requested that the Examiner withdraw the rejection of the claims under 35 USC 
§103. 
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SUMMARY 

An early Notice of Allowance is earnestly solicited. If there are any issues remaining 
which the Examiner believes could be resolved through either a Supplemental Response or 
an Examiner's Amendment, the Examiner is respectfully requested to contact the undersigned 
attorney at the telephone number listed below. 



m aintain the pendency of this case, and any required fee for such extension or any further fee 
required in connection with the filing of this Amendment is to be charged to Deposit Account 
No. 50-0388 (Order No. ANDIP001). 



Applicants hereby petition for an extension of time which may be required to 



Respectfully submitted, 
BEYER WEAVER IXP 




Elise R. Heilbrunn 
Reg. No. 42,649 



PO Box 70250 



Oakland, CA 94612-0250 
(510)663-1100 
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